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Status of This Memo 


This memo provides information for the Internet community. It does 
not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 


Abstract 


This document describes how a Mobile IPv6 Fast Handover can be 
implemented on link layers conforming to the IEEE 802.16e suite of 
specifications. The proposed scheme tries to achieve seamless 
handover by exploiting the link-layer handover indicators and thereby 
synchronizing the IEEE 802.16e handover procedures with the Mobile 
IPv6 fast handover procedures efficiently. 
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1. Introduction 


Mobile IPv6 Fast Handover protocol (FMIPv6) [RFC5268] was proposed to 
complement the Mobile IPv6 (MIPv6) [RFC3775] by reducing the handover 
latency for the real-time traffic. FMIPv6 assumes the support from 
the link-layer technology; however, the specific link-layer 
information available and its available timing differs according to 
the particular link-layer technology in use, as pointed out in 
[RFC4260], which provides an FMIPv6 solution for the IEEE 802.11 
networks. So, this document is proposed to provide an informational 
guide to the developers about how to optimize the FMIPv6 handover 
procedures, specifically in the IEEE 802.16e networks 

[IEEE802.16] [IEEE802.16e]. 


The proposed scheme achieves seamless handover by exploiting the 
link-layer handover indicators and designing an efficient 
interleaving scheme of the 802.16e and the FMIPv6é handover 
procedures. The scheme targets a hard handover, which is the default 
handover type of IEEE 802.16e. For the other handover types, i.e., 
the Macro Diversity Handover (MDHO) and Fast Base Station Switching 
(FBSS), the base stations in the same diversity set are likely to 
belong to the same subnet for diversity, and FMIPv6 might not be 
needed. Regarding the MDHO and the FBSS deployment with FMIPv6, 
further discussion will be needed and is not in the scope of this 
document. 
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We begin with a summary of handover procedures of [IEEE802.16e] and 
then present the optimized complete FMIPv6 handover procedures by 


using the link-layer handover indicators. The examples of handover 
scenarios are described for both the predictive mode and reactive 
mode. 

2. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document is to be interpreted as described in [RFC2119]. 


Most of terms used in this document are defined in MIPv6 [RFC3775] 
and FMIPv6 [RFC5268]. 


The following terms come from the IEEE 802.16e specification 
[IEEE802.16e]. 


MOB_NBR-ADV 


An IEEE 802.16e neighbor advertisement message sent 
periodically by a base station. 


MOB_MSHO-REQ 


An IEEE 802.16e handover request message sent by a mobile node. 


MOB_BSHO-RSP 


An IEEE 802.16e handover response message sent by a base 
station. 


MOB_BSHO-REQ 


An IEEE 802.16e handover request message sent by a base 
station. 


MOB_HO-IND 


An IEEE 802.16e handover indication message sent by a mobile 
node. 


BSID 


An IEEE 802.16e base station identifier. 


Jang, et al. Informational [Page 3] 


RFC 5270 FMIPv6 over 802.16e June 2008 


3- 


IEEE 802.16e Handover Overview 


Compared with the handover in the WLAN (Wireless Local Area Network), 
the IEEE 802.16e handover mechanism consists of more steps since the 
802.16e embraces the functionality for elaborate parameter adjustment 
and procedural flexibility. 


When a mobile node (MN) stays in a link, it listens to the Layer 2 
neighbor advertisement messages, named MOB_NBR-ADV, from its serving 
base station (BS). A BS broadcasts them periodically to identify the 
network and announce the characteristics of neighbor BSs. Receiving 
this, the MN decodes this message to find out information about the 
parameters of neighbor BSs for its future handover. With the 
provided information in a MOB_NBR-ADV, the MN may minimize the 
handover latency by obtaining the channel number of neighbors and 
reducing the scanning time, or may select the better target BS based 
on the signal strength, Quality-of-Service (QoS) level, service 
price, etc. 


The handover procedure is conceptually divided into two steps: 
"handover preparation" and "handover execution" [SH802.16e]. The 
handover preparation can be initiated by either an MN or a BS. 


During this period, neighbors are compared by the metrics such as 
signal strength or QoS parameters, and a target BS is selected among 
them. If necessary, the MN may try to associate (initial ranging) 
with candidate BSs to expedite a future handover. Once the MN 
decides to handover, it notifies its intent by sending a MOB_MSHO-REQ 


message to the serving BS (s-BS). The BS then replies with a 
MOB_BSHO-RSP containing the recommended BSs to the MN after 
negotiating with candidates. Optionally, it may confirm handover to 


the target BS (t-BS) over backbone when the target is decided. 
Alternatively, the BS may trigger handover with a MOB _BSHO-REQ 
message. 


After handover preparation, handover execution starts. The MN sends 
a MOB_HO-IND message to the serving BS as a final indication of its 
handover. Once it makes a new attachment, it conducts 802.16e 
ranging through which it can acquire physical parameters from the 
target BS, tuning its parameters to the target BS. After ranging 
with the target BS successfully, the MN negotiates basic capabilities 
such as maximum transmit power and modulator/demodulator type. It 
then performs authentication and key exchange procedures, and finally 
registers with the target BS. If the target BS has already learned 
some contexts such as authentication or capability parameters through 


backbone, it may omit the corresponding procedures. For the details 
of the 802.16 handover procedures, refer to Section 6.3.22 of 
[IEEE802.16e]. After completing registration, the target BS starts 
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to serve the MN and communication via target BS is available. 
However, in case the MN moves to a different subnet, it should 
reconfigure a new IP address and reestablish an IP connection. To 
resume the active session of the previous link, the MN should also 
perform IP layer handover. 


4. Network Topology Acquisition and Network Selection 


This section describes how discovery of adjacent networks and 
selection of target network work in the IEEE 802.16e for background 
information. 


An MN can learn the network topology and acquire the link information 
in several ways. First of all, it can do that via L2 neighbor 
advertisements. A BS supporting mobile functionality shall broadcast 
a MOB_NBR-ADV message periodically that includes the network topology 
information (its maximum interval is 1 second). This message 
includes BSIDs and channel information of neighbor BSs, and it is 
used to facilitate the MN’s synchronization with neighbor BSs. An MN 
can collect the necessary information of the neighbor BSs through 
this message for its future handover. 


Another method for acquisition of network topology is scanning, which 
is the process to seek and monitor available BSs in order to find 
suitable handover targets. While a MOB_NBR-ADV message includes 
static information about neighbor BSs, scanning provides rather 
dynamic parameters such as link quality parameters. Since the 
MOB_NBR-ADV message delivers a list of neighbor BSIDs periodically 
and scanning provides a way to sort out some adequate BSs, it is 
recommended that when new BSs are found in the advertisement, the MN 
identifies them via scanning and resolves their BSIDs to the 
information of the subnet where the BS is connected. The 
association, an optional initial ranging procedure occurring during 
scanning, is one of the helpful methods to facilitate the impending 
handover. The MN is able to get ranging parameters and service 
availability information for the purpose of proper selection of the 
target BS and expediting a potential future handover to it. The 
detailed explanation of association is described in Section 6.3.22 of 
[IEEE802.16e]. 


Besides the methods provided by 802.16e, the MN may rely on other 
schemes. For instance, the topology information may be provided 
through the MIIS (Media Independent Information Service) 

[IEEE802.21], which has been developed by the IEEE 802.21 working 
group. The MIIS is a framework by which the MN or network can obtain 
network information to facilitate network selection and handovers. 
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After learning about neighbors, the MN may compare them to find a BS, 
which can serve better than the serving BS. The target BS may be 
determined by considering various criteria such as required QoS, 
cost, user preference, and policy. How to select the target BS is 
not in the scope of this document. 


53 Interaction between FMIPv6 and IEEE 802.16e 


In this section, a set of primitives is introduced for an efficient 
interleaving of the IEEE 802.16e and the FMIPv6 procedures as below. 
The following sections present the handover procedures in detail by 
using them. 


o NEW_LINK_DETECTED (NLD) 


A trigger from the link layer to the IP layer in the MN to 
report that a new link has been detected. 


o LINK_HANDOVER_IMPEND (LHI) 


A trigger from the link layer to the IP layer in the MN to 
report that a link-layer handover decision has been made and 
its execution is imminent. 


o LINK_SWITCH (LSW) 


A control command from the IP layer to the link layer in the MN 
in order to force the MN to switch from an old BS to a new BS. 


o LINK_UP (LUP) 


A trigger from the link layer to the IP layer in the MN to 
report that the MN completes the link-layer connection 
establishment with a new BS. 


5.1. Access Router Discovery 


Once a new BS is detected through reception of a MOB_NBR-ADV and 
scanning, an MN may try to learn the associated access router (AR) 
information as soon as possible. In order to enable its quick 
discovery in the IP layer, the link layer (802.16) triggers a 
NEW_LINK_DETECTED primitive to the IP layer (FMIPv6) on detecting a 
new BS. 


Receiving the NEW_LINK_DETECTED from the link layer, the IP layer 
tries to learn the associated AR information by exchanging an RtSolPr 
(Router Solicitation for Proxy Advertisement) and a PrRtAdv (Proxy 
Router Advertisement) with the PAR (Previous Access Router). 
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According to [RFC5268], the MN may send an RtSolPr at any convenient 
time. However, this proposal recommends that, if feasible, the MN 
send it as soon as possible after receiving the NEW_LINK_DETECTED for 
quick router discovery because detection of a new BS usually implies 
MN’s movement, which may result in handover. 


Transmission of RtSolPr messages may cause the signaling overhead 
problem that is mentioned in Section 2 of [RFC4907]. To rate-limit 
the retransmitted RtSolPr messages, FMIPv6 provides a back-off 
mechanism. It is also possible that attackers may forge a MOB_NBR- 
ADV message so that it can contain a bunch of bogus BSIDs or may send 
a flood of MOB_NBR-ADV messages each of which contains different 
BSIDs. This problem is mentioned in Section 8. 


5.2. Handover Preparation 


When the MN decides to change links based on its policy such as the 
degrading signal strength or increasing packet loss rate, it 
initiates handover by sending a MOB_MSHO-REQ to the BS and will 
receive a MOB _BSHO-RSP from the BS as a response. Alternatively, the 
BS may initiate handover by sending a MOB_BSHO-REQ to the MN. 


On receiving either a MOB_BSHO-RSP or a MOB_BSHO-REQ, the link layer 
triggers a LINK_HANDOVER_IMPEND in order to signal the IP layer of 
arrival of MOB_BSHO-REQ/MOB_BSHO-RSP quickly. At this time, the 
target BS decided in the link layer is delivered to the IP layer as a 


parameter of the primitive. The primitive is used to report that a 
link-layer handover decision has been made and its execution is 
imminent. It can be helpfully used for FMIPv6 as an indication to 


start the handover preparation procedure, that is to send an FBU 
(Fast Binding Update) message to the PAR. 


To avoid erroneous results due to unreliable and inconsistent 
characteristics of link, for instance, to move to the unpredicted 
network or to stay in the current network after sending an FBU, 
Section 2 of [RFC4907] advises the use of a combination of signal 
strength data with other techniques rather than relying only on 
signal strength for handover decision. For example, the 
LINK_HANDOVER_IMPEND may be sent after validating filtered signal 
strength measurements with other indications of link loss such as 
lack of beacon reception. 


Once the IP layer receives the LINK_HANDOVER_IMPEND, it checks 
whether or not the specified target network belongs to a different 
subnet based on the information collected during the Access Router 
Discovery step. If the target proves to be in the same subnet, the 
MN can continue to use the current IP address after handover, and 
there is no need to perform FMIPv6. Otherwise, the IP layer 
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formulates a prospective NCoA (New Care-of Address) with the 
information provided in the PrRtAdv message and sends an FBU message 
to the PAR. 


When the FBU message arrives in the PAR successfully, the PAR and the 
NAR (New Access Router) process it according to [RFC5268]. The PAR 
sets up a tunnel between the PCoA (Previous Care-of Address) and NCoA 
by exchanging HI (Handover Initiate) and HAck (Handover Acknowledge) 
messages with the NAR, forwarding the packets destined for the MN to 
the NCoA. The NCoA is confirmed or re-assigned by the NAR in the 
HAck and, finally delivered to the MN through the FBack (Fast Binding 
Acknowledgment) in case of predictive mode. 


After the MN sends a MOB_HO-IND to the serving BS, data packet 
transfer between the MN and the BS is no longer allowed. Note that 
when a MOB_HO-IND is sent out before an FBack arrives in the MN, it 
is highly probable that the MN will operate in reactive mode because 
the serving BS releases all the MN’s connections and resources after 
receiving a MOB_HO-IND. Therefore, if possible, the MN should 
exchange FBU and FBack messages with the PAR before sending a MOB_HO- 
IND to the BS so as to operate in predictive mode. 


5.3. Handover Execution 


If the MN receives an FBack message on the previous link, it runs in 
predictive mode after handover. Otherwise, it should run in reactive 
mode. In order for the MN to operate in predictive mode as far as 
possible after handover, implementations may allow use of a 
LINK_SWITCH primitive. The LINK_SWITCH is a command in order to 
force the MN to switch from an old BS to a new BS and the similar 
concept has introduced for the wireless LAN in [RFC5184]. When it is 
applied, the MN’s IP layer issues a LINK_SWITCH primitive to the link 
layer on receiving the FBack message in the previous link. Until it 
occurs, the link layer keeps the current (previous) link if feasible 
and postpones sending a MOB_HO-IND message while waiting for the 
FBack message. 


After switching links, the MN synchronizes with the target BS and 


performs the 802.16e network entry procedure. The MN exchanges the 
RNG-REQ/RSP, SBC-REQ/RSP, PKM-REQ/RSP, and REG-REQ/RSP messages with 
the target BS. Some of these messages may be omitted if the 


(previously) serving BS transferred the context to the target BS over 
the backbone beforehand. When the network entry procedure is 
completed and the link layer is ready for data transmission, it 
informs the IP layer of the fact with a LINK_UP primitive. 
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Section 2 of [RFC4907] recommends that link indications should be 
designed with built-in damping. The LINK_UP primitive defined in 
this document is generated by the link layer state machine based on 
the 802.16e link layer message exchanges, that is, the IEEE 802.16e 
network entry and the service flow creation procedures. Therefore, 
the LINK_UP is typically less sensitive to changes in transient link 
conditions. The link may experience an intermittent loss. Even in 
such a case, the following FMIPv6 operation is performed only when 
the MN handovers to the link with a different subnet and there is no 
signaling overhead as a result of a intermittent loss. 


5.4. Handover Completion 


When the MN’s IP layer receives a LINK_UP primitive from the link 
layer, it should check whether it has moved into the target network 
predicted by FMIPv6. In case the target BS is within the same 
subnet, the MN does not perform the FMIPv6 operation. 


* If the MN discovers itself in the predicted target network and 
receives an FBack message in the previous link, the MN’s IP 
layer sends an UNA (Unsolicited Neighbor Advertisement) to the 
NAR (predictive mode). 


* If the MN has moved to the target network without receiving an 
FBack message in the previous link, the IP layer sends an UNA 
and also an FBU message immediately after sending the UNA 
message (reactive mode). The NAR may provide a different IP 
address by using an RA (Router Advertisement) with a NAACK 
(Neighbor Advertisement Acknowledge) option other than the 
formulated NCoA by the MN. 


* The MN may discover itself in the unpredicted network 
(erroneous movement). If this is the case, the MN moves to the 
network that is not the target specified in the 
LINK_HANDOVER_IMPEND primitive. For the recovery from such an 
invalid indication, which is mentioned in Section 2 of 
[RFC4907], the MN should send a new FBU to the PAR according to 
Section 5.6 of [RFC5268] so that the PAR can update the 
existing binding entry and redirect the packets to the new 
confirmed location. 


In both cases of predictive and reactive modes, once the MN has moved 
into the new link, it uses the NCoA formulated by the MN as a source 
address of the UNA, irrespective of NCoA availability. It then 
starts a Duplicate Address Detection (DAD) probe for NCoA according 


to [RFC4862]. In case the NAR provides the MN with a new NCoA, the 
MN MUST use the provided NCoA instead of the NCoA formulated by the 
MN. 
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When the NAR receives an UNA message, it deletes its proxy neighbor 
cache entry if it exists, and forwards buffered packets to the MN 
after updating the neighbor cache properly. Detailed UNA processing 
rules are specified in Section 6.4 of [RFC5268]. 


6. The Examples of Handover Scenario 


In this section, the recommended handover procedures over 802.16e 
network are shown for both predictive and reactive modes. It is 
assumed that the MN handovers to the network that belongs to a 
different subnet. 


In the following figures, the messages between the MN’s Layer 2 (MN 
L2) and the BS are the IEEE 802.16 messages, while messages between 
the MN’s Layer 3 (MN L3) and the PAR and messages between PAR and NAR 
are the FMIPv6 messages. The messages between the MN L2 and the MN 
L3 are primitives introduced in this document. 


6.1. Predictive Mode 


The handover procedures in the predictive mode are briefly described 


as follows. Figure 3 illustrates these procedures. 
Tz A BS broadcasts a MOB_NBR-ADV periodically. 
2. If the MN discovers a new neighbor BS in this message, it may 


perform scanning for the BS. 


Bi When a new BS is found through the MOB_NBR-ADV and scanning, 
the MN’s link layer notifies it to the IP layer by a 
NEW_LINK_DETECTED primitive. 


4. The MN tries to resolve the new BS’s BSID to the associated 
AR by exchange of RtSolPr and PrRtAdv messages with the PAR. 


53 The MN initiates handover by sending a MOB_MSHO-REQ message 
to the BS and receives a MOB_BSHO-RSP from the BS. 
Alternatively, the BS may initiate handover by sending a 
MOB_BSHO-REQ to the MN. 


6. When the MN receives either a MOB_BSHO-RSP or a MOB_BSHO-REQ 
from the BS, its link layer triggers a LINK_HANDOVER_IMPEND 
primitive to the IP layer. 
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Te On reception of the LINK_HANDOVER_IMPEND, the MN’s IP layer 
identifies that the target delivered along with the 
LINK_HANDOVER_IMPEND belongs to a different subnet and sends 
an FBU message to the PAR. On receiving this message, the 
PAR establishes tunnel between the PCoA and the NCoA by 
exchange of HI and HAck messages with the NAR, and it 
forwards packets destined for the MN to the NCoA. During 
this time, the NAR may confirm NCoA availability in the new 
link via HAck. 


8. The MN receives the FBack message before its handover and 
sends a MOB_HO-IND message as a final indication of handover. 
Issue of a MOB_HO-IND may be promoted optionally by using a 
LINK_SWITCH command from the IP layer. Afterwards it 
operates in predictive mode in the new link. 


9:3 The MN conducts handover to the target BS and performs the 
TEEE 802.16e network entry procedure. 


10. As soon as the network entry procedure is completed, the MN’s 
link layer signals the IP layer with a LINK_UP. On receiving 
this, the IP layer identifies that it has moved to a 
predicted target network and received the FBack message in 
the previous link. It issues an UNA to the NAR by using the 
NCoA as a source IP address. At the same time, it starts to 
perform DAD for the NCOoA. 


11. When the NAR receives the UNA from the MN, it delivers the 
buffered packets to the MN. 
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(MN L3 MN L2) s-BS PAR t-BS NAR 
| | | | | 
1-2. <---MOB_NBR-ADV -------- 
LSF Scanning------- > 
3. | <nnp-| | | | | 
4 | -------------- (RtSolPr) -------------- > | | | 
|<-------------- PrRtAdv---------------- | | 
| | | | | | 
Of. OW hie eee MOB_MSHO-REQ----- > 
<----- MOB_BSHO-RSP------ 
| | or | | | | 
| |<----- MOB_BSHO-REQ------ | | | 
6. f<-rmr-| | | | | 
Te | ------------------ FBU---------------- > | | | 
| | | |-------- HI-------- >| 
| | <------ HACK-------- 
GPSS RSS SSS SS sso PBaGCk = roe HSS SSS SSraa | Se > 
| Packets > | 
8. | (LSW) > |------- MOB_HO-IND------ >| | | 
disconnect | | | | | 
connect | | | | | 
F; <--------- IEEE 802.16 network entry-------- > 
10 <-LUP- | 
---------------------------- UNA--------------------------> | 
iis |< Packets 
| | | | | 
Figure 3. Predictive Fast Handover in 802.16e 
6.2. Reactive Mode 
The handover procedures in the reactive mode are described as 
follows. Figure 4 is illustrating these procedures. 
1. ~ 7. The same as procedures of predictive mode. 
8. The MN does not receive the FBack message before handover and 


sends a MOB_HO-IND message as a final indication of handover. 
Afterwards, it operates in reactive mode in the new link. 


Os The MN conducts handover to the target network and performs 
the 802.16e network entry procedure. 
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10. As soon as the network entry procedure is completed, the MN’s 
link layer signals the IP layer with a LINK_UP. On receiving 
this, the IP layer identifies that it has moved to the 
predicted target network without receiving the FBack in the 
previous link. The MN issues an UNA to the NAR by using NCoA 
as a source IP address and starts to perform DAD for the 
NCoA. Additionally, it sends an FBU to the PAR in the 
reactive mode. 

11. When the NAR receives the UNA and the FBU from the MN, it 
forwards the FBack to the PAR. The FBack and Packets are 
forwarded from the PAR and delivered to the MN (NCoA) through 
the NAR. The NAR may supply a different IP address than the 
NCoA by sending an RA with a NAACK option to the MN. 

Ba MN L2) i ria gg iän 
1-2. | |<---MOB_NBR-ADV & Scan--| | | 
| |<------- Scanning------- >| | | 
3. |<-N1D-]| | | | | 
4. |-------------- (RtSolPr)-------------- >| | 
nea -------- E ------ | | 
5g | |------ MOB_MSHO-REQ----- >| | | 
| |<----- MOB_BSHO-RSP------ | | | 
| | or | | | | 
| |<----- MOB_BSHO-REQ------ | | | 
6. <-LHI- | | | | 
qs. (STs FBU----X---—> 
8. | |------- MOB_HO-IND------ >| | | 
disconnect | | | | | 
connect | | | | 
9. |<--------- IEEE 802.16 network entry-------- >| 
16. <-LUP- | | 
----------------------—--—-— UNA--------------------------> 
| ---------------------------- FBU-------------------------- ) | 
LI; | | | <------- FBU------- ) | 
| | | |<----- HI/HAck----- >| 
| | | | (if necessary) | 
| | Packets & FBack=========> 
< 


Figure 4. Reactive Fast Handover in 802.16e 
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7. 


IEEE 802.21 Considerations 


It is worth noting that great research has been conducted on defining 
generic services in the IEEE 802.21 working group that facilitate 
handovers between heterogeneous access links. The standard works are 
named as a Media Independent Handover (MIH) Service [IEEE802.21], and 
propose three kinds of services: Media Independent Event Service 
(MIES), Media Independent Command Service (MICS), and Media 
Independent Information Service (MIIS). 


An MIES defines the events triggered from lower layers (physical and 
link) to higher layers (network and above) in order to report changes 
of physical and link-layer conditions. On the other hand, an MICS 
supports the commands sent from higher layers to lower layers, and it 
provides users with a way of managing the link behavior relevant to 
handovers and mobility. An MIIS provides a framework by which the MN 
or network can obtain network information to facilitate network 
selection and handovers. 


Although the purpose of IEEE 802.21 has been developed to enhance the 
user experience of MNs roaming between heterogeneous networks, the 
results may be utilized to optimize the handover performance ina 
homogeneous network. When the MIH primitives are available for 
handover in the 802.16e network, the MN can use them instead of the 
primitives proposed in this document. Table 1 shows examples of the 
mapping between the proposed primitives and the MIH primitives. 


4+------------------------- 4------------------------- + 
| Proposed primitives | MIH primitives 

+ + 
| NEW_LINK_DETECTED | LINK_DETECTED | 
4----------------------- = ----- = = = = = = + 
| LINK_HANDOVER_IMPEND | LINK_HANDOVER_IMMINENT | 
4--------------------------- = = = 5 == = + 
| LINK_SWITCH | HANDOVER_COMMIT | 
4+---------------------- = -- -- = = == = = = == == = + 
| LINK_UP | LINK_UP | 
4----------------------- = - = - = = = = = + 


Table 1. The Proposed Primitives and MIH Primitives 
Security Considerations 


The primitives defined in this document are used only for local 
indication inside of the MN, so no security mechanism is required to 
protect those primitives. However, FMIPv6 messages and IEEE 802.16e 
messages, which may trigger the primitives, need to be protected. 
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10. 


10. 


Security considerations of the FMIPv6 specification [RFC5268] are 
applicable to this document. It is also worthwhile to note that the 
TEEE802.16e has a security sub-layer that provides subscribers with 
privacy and authentication over the broadband wireless network. This 
layer has two main component protocols: a privacy key management 
protocol (PKM) for key management and authentication and an 
encapsulation protocol for encrypting data. From the perspective of 
the 802.16e, FMIPv6 messages are considered as data and are delivered 
securely by using those protocols. 


However, some of IEEE 802.16e management messages are sent without 
authentication. For example, there is no protection to secure 
802.16e broadcast messages. It may be possible for the attacker to 
maliciously forge a MOB_NBR-ADV message so that it contains the bogus 
BSIDs, or send a flood of MOB_NBR-ADV messages having different bogus 
BSIDs toward the MN. As a result, the MN may trigger a bunch of 
NEW_LINK_DETECTED primitives and send useless consecutive RtSolPr 
messages to the PAR, finally resulting in wasting the air resources. 
Therefore, the MN SHOULD perform scanning when detecting new BSs in 
the received MOB _NBR-ADV messages in order to assure the included 
neighbor information. 


It is also possible that attackers try a DoS (Denial-of-Service) 
attack by sending a flood of MOB_BSHO-REQ messages and triggering 
LINK_HANDOVER_IMPEND primitives in the MN. But the IEEE 802.1l6e 
provides a message authentication scheme for management messages 
involved in handover as well as network entry procedures by using a 
message authentication code (MAC) such as HMAC/CMAC (hashed/cipher 
MAC). Thus, those management messages are protected from the 
malicious use by attackers who intend to trigger LINK_HANDOVER_IMPEND 
or LINK_UP primitives in the MN. 
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